ci: restore a working CI pipeline (pnpm setup, build order, Node 22, types) - #4

Two pre-existing bugs that the pnpm setup fix uncovered — both were
masked for weeks because every job died before running anything.

CI had no build step. Cross-package types resolve only through each
package's built dist/*.d.ts (no project references, no path mapping) and
dist/ is gitignored, so a clean checkout failed with TS2307 on every
@pi-managed/* import. Reproduced locally by moving packages/contracts/dist
aside; `pnpm build` before typecheck/test fixes it. Added to the
typecheck, test, and kvm jobs; lint needs no build and is left alone.

SpawnExecutor wrote the payload to child.stdin with no error listener on
that stream. When the spawn script exits before reading stdin — which the
close handler already treats as a legitimate error result — the pipe
closes and the write raises EPIPE, which without a listener becomes an
unhandled error that takes the process down instead. Verified with a
forced-race repro: without the listener the process dies with EPIPE
before the close handler finishes; with it, the intended error result is
returned. This crashed the worker in production, not just in tests.

`pnpm -r build` cannot order this workspace. testkit depends on backend
for port types while backend keeps testkit as a devDependency, and pnpm
resolves that cycle by building testkit first — which fails on any clean
tree, since cross-package types resolve only through the gitignored
dist/*.d.ts (no project references, no path mapping).

This is why CI still failed after adding the build step, and it means
`pnpm build` has never worked on a fresh clone either; every local run
succeeded only against stale dist artifacts.

Build everything except testkit first, then testkit. Verified by removing
all packages/*/dist and running the script from scratch: all 7 packages
build, typecheck is clean. Documented the constraint in architecture.md
3.2 next to the cycle it follows from.

The embedded Pi agent (@earendil-works/pi-coding-agent) pulls undici
8.5.0, whose engines field is >=22.19.0. On Node 20 it throws
"webidl.util.markAsUncloneable is not a function" at import time, which
is what was failing the client-extension suites in CI — the declared
floor was simply below what a dependency required. Node 20 is also EOL.

Raise engines to >=22.19.0, move every workflow to node-version 22, and
update the prerequisite wherever it is stated (README, getting-started,
deploy x2, user-journeys, spec.md, and the KVM runner notes in ci.yml),
recording the reason so the number is not later lowered on a guess.

@types/node was pinned at ^26.1.1 while the runtime floor is 22.19, so
typecheck was validating against APIs the target runtime does not have —
the same class of gap that let the undici/Node 20 break reach CI.

Pin all three declarations (root, worker, billing-adapter) to ^22.20.1.

Doing so surfaced one real error: fileStream() in jsonl-sync typed its
data handler as (chunk: Buffer), but Readable's data event is
string | Buffer. The stream is created locally with no encoding so
chunks are always Buffer; narrow at that boundary and say why.

The large-streaming ObjectStore case asserted with toEqual on a 2 MiB
Uint8Array, which vitest walks element by element: 2432ms of the suite's
2551ms, and a timeout against the 5s default on a shared CI runner.

Buffer.compare gives the identical byte-exact guarantee natively — the
test drops to 9ms. The small-payload case keeps toEqual, where the
element-wise diff is cheap and worth having on failure.

Both surfaced on the first backend run in weeks; neither is a weakening.

contract.test.ts duplicates the testkit ObjectStore conformance suite by
hand rather than importing the kit, so it carried the same 2 MiB toEqual
that timed out the 5s default — here three times over (Fake, Filesystem,
GCS). Same native Buffer.compare fix, same guarantee. Worth noting the
duplication itself: the two copies must be kept in sync by hand.

The ROB-22 catch-up storm enumerates 5,200 minute-occurrences and inserts
5,200 rows, twice. Its author already flagged it slow and set 60s, which
held on developer hardware but not on a 2-core runner sharing the box
with the parallel suites. Raised to the package's 180s hookTimeout.

The concurrency test asserted that the entry last in (created_at DESC,
id DESC) carries the final balance. Nothing can identify the last-APPLIED
entry that way: created_at defaults to now(), which is transaction-START
time in Postgres and so does not track the order 40 concurrent
transactions take the FOR UPDATE lock, and id is a random newId(). The
assertion only ever passed on timing luck; on CI it read 1000100.

The ledger itself is correct — appendEntry serializes every credit and
debit under FOR UPDATE on tenant_billing, and the two authoritative
assertions (final balance 1_000_000, all 41 entries present) both passed.
Drop the ordering assertion and its now-dead subquery, recording why it
cannot be asserted so it is not reintroduced.

The pool test sampled rtB.status() once, immediately after sendEvent
resolved. sendEvent returns when the event is accepted; the turn settles
back to idle asynchronously after that, so on a loaded CI runner the
sample caught 'running'.

Poll with the waitFor helper already used a few lines above for the
respawn. This keeps the assertion's strength — a session that never
leaves 'running' still fails when waitFor times out at 10s.

Every test file passed but the job still exited 1: vitest caught two
unhandled errors, both Postgres 57P01 (admin_shutdown) raised when
testcontainers stopped the database while pooled connections were open.

The cause is production code, not the tests. createPool never attached an
'error' listener, and pg emits that event on IDLE pooled clients whenever
the server drops them — a restart, a failover, or pg_terminate_backend.
In Node an 'error' event with no listener is fatal, so a routine Postgres
restart would have taken the backend process down. The pool discards the
dead client itself and stays usable, and an error on a checked-out client
still rejects that client's own query, so the listener hides nothing a
caller would otherwise observe.